IBIS Macromodel Task Group Meeting date: 08 November 2016 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai * Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki * Ming Yan Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Walter to put the file name relaxation proposal into a BIRD format. - In progress. - Michael Mirmak to update his Format and Usage Out Clarifications BIRD draft based on the discussions. - In progress. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Walter: Motion to approve the minutes. - Dan: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: Relaxation of IBIS filename restrictions: - Walter: [sharing the most recent proposal email (with rev3 of the proposal)] - Latest email has a brief explanation of the relative path directory: - I think the only issue that is in contention is if "Path Names" in a "File" referenced in an "IBIS File" shall be relative to the directory containing the "File" or the directory containing the "IBIS File". The answer must be relative to the directory containing the "File". How else could you use this same AMI model or Interconnect Model Set file in different "IBIS Files". - Arpad: Because the particular file may not even know where its top level parent .ibs file is. So it can't contain paths relative to the directory containing the top level .ibs file. - Walter: Exactly. - Discussion: Bob and Radek agreed with Walter's proposal and Arpad's statement. Radek noted that his objections in the previous week's meeting were caused by confusion over the use of the term "parent file" in the original draft, which Walter had meant to be the file containing the reference but others including Radek had thought was a reference to the top level .ibs file. All were in agreement that file name entries made in any file (.ibs, .ebd, .pkg, etc.) should be relative to the directory containing that file. - Walter: [Reviewing proposed changes to the [File Name] keyword] - I've added a separate bullet for each of 3 rules. - I've added a new statement that there may not be a "/" in the file name. - This is the easiest way to address Bob's requirement that the [File Name] keyword itself must still contain a name only (no path). - After reviewing the spec. again, I found that there are several places that prohibit "/" at the end of the filename, so I've re-introduced that restriction to this version of the proposal. - Proposed changes to BIRD 147.3: - Replacing the existing "alphanumeric identifier" language for BCI_ID with text referring to the general file name guidelines. - Bob R.: Technically (as defined in Section 3), the file name extension is the part after the "." (e.g., "ami", "ibs", "pkg" "ebd"). - Walter: References to ".ami", etc. are ubiquitous. I don't want to tackle that cleanup now, but I agree it should be done. - Discussion: Bob wanted to replace uses of the word "folder" with directory or subdirectory. Walter agreed. Bob expressed concern about the appearance of fully qualified paths in the examples. Walter noted that these paths were given for illustrative purposes only, and were there to show the actual file hierarchy that existed and corresponded to the given IBIS file name examples. However, Walter agreed to remove the absolute path information from the examples. - Bob R.: DLL_ID could use the same language change as BCI_ID. - Walter: We could do that. I will make that change. - Bob R.: I'm not sure if expanding DLL_ID to allow path information could cause conflicts with DLL_PATH. - Arpad: Perhaps we could say that the DLL_ID path is relative to the DLL_PATH? - Bob R.: That might be one way to resolve it. I'm not sure we have to resolve anything. I just want us to think about any interactions we might cause. - Bob M.: DLL_PATH is a path to the directory where the .dll executable came from. - That is completely different from DLL_ID, which, if it has a directory associated with it, would be a working directory path. - DLL_PATH allows the executable model to find other things it might rely on. - Bob R.: We don't have a separate BCI_PATH because we don't need it. - Bob M.: Yes, we don't need a search path in that application, just the way to specify a working directory. - Bob R.: The changes Walter is proposing are valid for BCI_ID and DLL_ID. - Bob M.: Yes, I believe so. - Bob R.: I will revise BIRD 147.3 to adopt the new language for BCI_ID. - Walter: I will update draft 3 to make draft 4 and send it out for Mike LaBonte to post. Bob Ross and Radek's discussion of Editorial Task Group Issues: - Bob R.: Summary: - Discussed more about a proposed [Local Reference] keyword. - Now working on the terminal names related to [Local Reference] and all the other [* Reference] keywords. - More work on the node-collapse rule, whereby if values of two [* Reference] keywords' voltages are all the same then their nodes can be considered one. - We've discovered an exception that may be legal with a [Pin Mapping]. If you have two nodes that would be collapsed, for example the [Pullup Reference] and [POWER Clamp Reference] values are all the same, but in the [Pin Mapping] the pullup_ref and power_clamp_ref columns specify different bus labels, then you might still have two separate supply paths. You would need to preserve a different routing to those two nodes. We have to think about this case some more. - Phraseology issue: - For [* Reference] keywords, their descriptions state: "Defines a voltage rail other than that defined by" [Voltage Range] or 0. - We should state that it defines a voltage rail that "overrides" the [Voltage Range]. - Radek: In other words, "other than" is incorrect. - We also have an interrelated issue with BIRD 181.2, where the definition of the I/V tables is via providing nodes for the pad and the power and ground supplies, and those nodes are not really clearly defined in the spec. - Bob R.: Yes, there's an attempt to list the nodes but they're never formally defined. - Arpad: One final question. Should we cancel the meeting on the week of Thanksgiving (meeting on November 22)? - Radek: I move that we cancel the meeting on November 22. - Ambrish: Second. - Arpad: Anyone opposed? [none] - Okay, so we will meet next week (November 15), but not on November 22. - Walter: Motion to adjourn. - Bob R.: Second. - Arpad: Thank you all for joining. AR: Walter to create draft 4 of the file name relaxation proposal and send it to the ATM list (for Mike LaBonte to post). AR: Bob R. to create BIRD 147.4 to incorporate discussed changes to BCI_ID. ------------- Next meeting: 15 November 2016 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives